Configuring the Root of Trust

CCC relies on a hardware-backed Root of Trust (ROT) to establish the cryptographic foundation of the platform. The Root of Trust is created within a dedicated partition on a Luna Network HSM and protects sensitive cryptographic material, including internal encryption keys and secure service credentials. By anchoring these operations to a hardware security boundary, CCC ensures that key material is generated, stored, and protected within the HSM rather than solely in software, strengthening the overall security posture of the deployment.

The Root of Trust is established as part of the CCC installation workflow. After the required HSM parameters and credentials have been configured, CCC initializes the Root of Trust automatically during the first startup of the application. During this process, CCC connects to the Luna Network HSM over NTLS, authenticates to the designated partition, and creates its hardware-backed cryptographic trust anchor within the HSM boundary.

The sections below describe how the required HSM parameters are defined during installation, how the Root of Trust is initialized and validated, how High Availability is configured, and how to troubleshoot common Root of Trust–related issues.

Establishing the Root of Trust During CCC Installation Using Podman

When installing CCC using Podman, the HSM parameters required for Root of Trust initialization are defined within the standard installation workflow described on the Install CCC Using Podman page. To ensure that the Root of Trust is properly established during installation, verify that the following prerequisites and configuration steps are completed as part of the CCC installation process:

The Root of Trust is not configured through a separate or post-installation procedure. It is initialized automatically during the first startup of CCC once the required HSM parameters and credentials have been provided. The steps below are presented for technical clarity and reference.

sh start-ccc-server.sh

podman logs -f ccc

Establishing the Root of Trust During CCC Installation Using Kubernetes, Helm, or Azure

When installing CCC using Kubernetes, Helm, or Azure, the HSM parameters required for Root of Trust initialization are defined within the standard installation workflow described in the corresponding deployment guide. To ensure that the Root of Trust is properly established during installation, verify that the following prerequisites and configuration steps are completed as part of the CCC deployment process:

The Root of Trust is not configured through a separate or post-installation procedure. It is initialized automatically during the first startup of CCC once the required HSM parameters and credentials have been provided. The steps below are presented for technical clarity and reference.

kubectl create secret generic ccc-password \
--from-literal=HSM_PASSWORD1='password' \
--from-literal=CRYPTO_OFFICER_PASSWORD='password'

sh start-ccc-server.sh

kubectl logs -f deployment/ccc-deployment

High Availability (HA) Considerations

When enabling High Availability for the Root of Trust:

• ROT_HA_ENABLE must be set to Y.

• Both HSM partitions must have the same PARTITION_LABEL.

• Both partitions must belong to the same cloning domain.

• The secondary partition must be cloned from the primary.

• Both HSM devices must be reachable from the CCC host or cluster.

Failure to meet these conditions may result in initialization errors.

Root of Trust Troubleshooting

If CCC fails to start or displays errors related to HSM communication or partition authentication, the issue is likely related to Root of Trust configuration or connectivity. This section describes common Root of Trust–related issues and their resolution.

Root of Trust Initialization Failure

If the required HSM parameters are incorrect, the HSM is unreachable, or authentication to the designated partition fails, CCC will not complete startup successfully. In such cases, error messages related to NTLS communication or partition authentication will appear in the application logs. To resolve this issue:

"System Already Activated" Message

If you encounter the message "System already activated" while activating the Root of Trust, this indicates that the system has already been initialized with an existing ROT configuration. To proceed:

Device Status Errors After Changing the Root of Trust

If errors appear under the Device Status column after modifying or re-establishing the Root of Trust, the connected devices must be reconfigured. To resolve:

The device status should return to normal once reconfiguration is complete.

Issues After Changing HSM Passwords

If the HSM Admin password or Crypto Officer password is changed after the Root of Trust has been established, CCC will no longer be able to authenticate to the partition. To resolve:

• Update the corresponding password in the Podman secretfile, Kubernetes secret, or Helm secret.

• Restart the CCC container or redeploy the pods.

• Ensure credentials are consistent with the HSM configuration.

Issues After Changing HSM Certificates

If the certificate on the Luna Network HSM is replaced or updated:

• Restart the CCC container.

• Ensure NTLS trust is properly re-established.

• Verify that the updated certificate is recognized by CCC.

Enabling Detailed Logs for Diagnosis

If additional troubleshooting information is required, enable debug mode to capture detailed logs.

Podman

DEBUG_MODE='Y'

podman rm -f ccc
sh start-ccc-server.sh

Kubernetes/Helm/Azure

DEBUG_MODE='Y'

kubectl rollout restart deployment/ccc-deployment

Post-Diagnostic Validation

If issues persist after enabling debug mode and reviewing the logs, verify the following before attempting another startup:

• Network connectivity between CCC and the HSM

• Correct partition label and configuration

• Cloning domain consistency (if High Availability is enabled)

• Accuracy of Crypto Officer and HSM credentials

Important Clarification

The Root of Trust configuration applies exclusively to the HSM-backed cryptographic foundation of CCC. It does not apply to:

• The CA-signed certificate used to secure the CCC web interface and backend server (HTTPS).

• The SSL/TLS certificate used by the PostgreSQL database server.

• The NTLS CA certificate used for establishing trusted communication with the Luna Network HSM.

Each of these serves a different purpose and must be configured independently.